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Experience with the Label Distribution Protocol (LDP) 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


The purpose of this memo is to document how some of the requirements 
specified in RFC 1264 for advancing protocols developed by working 
groups within the IETF Routing Area to Draft Standard have been 
satisfied by LDP (Label Distribution Protocol). Specifically, this 
report documents operational experience with LDP, requirement 5 of 
section 5.0 in RFC 1264. 
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1. Introduction 


The purpose of this memo is to document how some of the requirements 
specified in [RFC1264] for advancing protocols developed by working 
groups within the IETF Routing Area to Draft Standard have been 
satisfied by LDP. Specifically, this report documents operational 
experience with LDP, requirement 5 of section 5.0 in RFC 1264. 


LDP was originally published as [RFC3036] in January 2001. It was 
produced by the MPLS Working Group of the IETF and was jointly 
authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre 
Fredette, and Bob Thomas. It has since been obsoleted by [RFC5036]. 


2. Operational Experience 


This section discusses operational experience with the protocol. The 
information is based on a survey sent to the MPLS Working Group in 
October 2004. The questionnaire can be found in the MPLS Working 
Group mail archives for October 2004. 


11 responses were received, all but 2 requesting confidentiality. 
The survey results are summarized to maintain confidentiality. The 
networks surveyed span different geographic locations: US, Europe, 
and Asia. Both academic and commercial networks responded to the 
survey. 


2.1. Environment and Duration 


The size of the deployments ranges from less than 20 Label Switching 
Routers (LSRs) to over 1000 LSRs. Eight out of the 11 deployments 
use LDP in the edge and the core, two on the edge only, and one in 
the core only. 


Sessions exist to peers discovered via both the basic and the 
extended discovery mechanisms. In half the cases, more than one 
adjacency (and as many as four adjacencies) are maintained per 
session. The average number of LDP sessions on an LSR ranges from 
under 10 to just over 80. The responses are spread out as follows: 
under 10: 4 responses, 20-50: 4 responses, and over 80: 1 response. 


In the surveyed networks, the time LDP has been deployed ranges from 
under 1 year to over 4 years. The responses are spread out as 
follows: under 1 year: 3 responses, 2 years: 2 responses, 3 years: 3 
responses, and over 4 years: 3 responses. 
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2.2. Applications and Motivation 


Nine of the 11 responses list Layer 3 Virtual Private Networks 
(L3VPNs) as the application driving the LDP deployment in the 
network. 


The list of applications is as follows: L3VPNs: 9, pseudowires: 4 
current (and one planned deployment), L2VPNs: 4, forwarding based on 
labels: 2, and BGP-free core: 1. 


There are two major options for label distribution protocols, LDP and 
Resource Reservation Protocol-Traffic Engineering (RSVP-TE). One of 
the key differences between the two is that RSVP-TE has support for 
traffic engineering, while LDP does not. The reasons cited for 
picking LDP as the label distribution protocol are: 


o The deployment does not require traffic engineering - 6 
o Inter-operability concerns if a different protocol is used - 5 


o Equipment vendor only supports LDP - 5 


o Ease of configuration - 4 

o Ease of management - 3 

o Scalability concerns with other protocols - 3 

o Required for a service offering of the service provider - 1 
2.3. Protocol Features 


All deployments surveyed use the Downstream Unsolicited Label 
Distribution mode. All but one deployment use Liberal Label 
retention (one uses conservative). 


LSP setup is established with both independent and Ordered Control. 
Five of the deployments use both control modes in the same network. 


The number of LDP Forwarding Equivalence Classes (FECs) advertised 
and LDP routes installed falls in one of two categories: 1) roughly 
the same as the number of LSRs in the network and 2) roughly the same 
as the number of IGP routes in the network. Of the 8 responses that 
were received, 6 were in the first category and 2 in the second. 
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2.4. Security Concerns 


A security concern was raised by one of the operators with respect to 
the lack of a mechanism for securing LDP Hellos. 


2.5. Implementations and Inter-Operability 


Eight of the 11 responses state that more than one implementation 
(and as many as four different ones) are deployed in the same 
network. 


The consensus is that although implementations differ, no inter- 
operability issues exist. The challenges listed by providers running 
multiple implementations are: 


o Different flexibility in picking for which FECs to advertise 
labels. 


o Different flexibility in setting transport and LDP router-id 
addresses. 


o Different default utilization of LDP labels for traffic 
resolution. Some vendors use LDP for both VPN and IPv4 traffic 
forwarding, while other vendors allow only VPN traffic to 
resolve via LDP. The challenge is to restrict the utilization 
of LDP labels to VPN traffic in a mixed-vendor environment. 


o Understanding the differences in the implementations. 
2.6. Operational Experience 


In general, operators reported stable implementations and steady 
improvement in resiliency to failure and convergence times over the 
years. Some operators reported that no issues were found with the 
protocol since deploying. 


The operational issues reported fall in three categories: 


1. Configuration issues. Both the session and adjacency endpoints 
must be allowed by the firewall filters. Misconfiguration of 
the filters causes sessions to drop (if already established) or 
not to establish. 


2. Vendor bugs. These include traffic blackholing, unnecessary 
label withdrawals and changes, session resets, and problems 
migrating from older versions of the technology. Most reports 
stated that the problems reported occurred in early versions of 
the implementations. 
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3. Protocol issues. 


- The synchronization required between LDP and the IGP was 
listed as the main protocol issue. Two issues were 
reported: 1) slow convergence, due to the fact that LDP 
convergence time is tied to the IGP convergence time, and 2) 
traffic blackholing on a link-up event. When an interface 
comes up, the LDP session may come up slower than the IGP 
session. This results in dropping MPLS traffic for a link- 
up event (not a failure but a restoration). This issue is 
described in more detail in [LDP-SYNC]. 


- Silent failures. Failure not being propagated to the head 
end of the LSP when setting up LSPs using independent 
control. 

3. Security Considerations 


This document is a survey of experiences from deployment of LDP 
implementations; it does not specify any protocol behavior. Thus, 
security issues introduced by the document are not discussed. 
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